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Software  Assurance  (SwA)  is  a  key  element  of  national  security;  it  is  critical  because  dramatic  increases  in  business  and 
mission  risks  are  attributable  to  exploitable  software  [1].  A  recent  Chief  Information  Office  (CIO)  Executive  Council 
poll  indicated  that  the  top  two  most  important  attributes  of  software  are  reliable  software  that  functions  as  promised  and 
software  free  from  security  vulnerabilities  and  malicious  code.  The  acquisition  process  can  be  leveraged  to  achieve  these 
important  attributes.  As  part  of  the  Department  of  Homeland  Security  (DHS)  and  Department  of  Defense  (DoD) 

SwA  initiative,  a  working  group  developed  a  guide,  Software  Assurance  in  Acquisition:  Mitigating  Risks  to  the 
Enterprise  <https:/ / buildsecurityin.us-cert.gov> ,  for  acquisition  officials  on  how  to  incorporate  SwA  considerations  in 
key  decisions  throughout  the  acquisition  process. 


Dependency  on  information  technolo¬ 
gy  (IT)  makes  SwA2  [2]  a  key  element 
of  national  security.  IT  in  critical  informa¬ 
tion  infrastructures  is  composed  of  sys¬ 
tems,  system  of  systems,  and  family  of 
systems  (SoS/FoS).  Most  of  these  systems 
involve  integrating  a  complex  value  chain 
of  commercial  off-the-shelf  (COTS), 
government  off-the-shelf  (GOTS),  open- 
source,  embedded,  and  legacy  software. 
Attackers  exploit  unintentional  vulnerabil¬ 
ities  or  insert  intentional  vulnerabilities 
into  these  software  components. 

In  a  2006  poll  taken  by  tire  CIO 
Executive  Council  on  the  impact  of  soft¬ 
ware  flaws,  vulnerabilities,  and  malicious 
code,  respondents  indicated  that  the  top 
two  most  important  attributes  of  software 
are  reliable  software  that  functions  as  promised 
(95  percent  of  respondents)  and  soflware 
free  from  security  vulnerabilities  and  malicious 
code  (70  percent  of  respondents)  [3], 

SwA  in  the  Acquisition 
Process 

A  broad  range  of  stakeholders  now  need 
justifiable  confidence  that  the  software 
which  enables  their  core  business  opera¬ 
tions  can  be  trusted  to  perform  (even  with 
attempted  exploitation)  and  contribute  to 
more  resilient  operations.  In  SoS/FoS, 
multiple  software  suppliers  are  usually 
involved.  Therefore,  the  responsibility  for 
SwA  must  now  be  shared  by  acquisition 
officials  and  supply  chain  constituents  — 
building  the  assurance  case  starts  with  the 
acquisition  process.  To  that  end,  acquisi¬ 
tion  officials3  involved  in  the  purchase  of 
software  services  or  products  have  a 
responsibility  to  factor  in  SwA  to  reduce 
tire  risk  of  exploitable  software  being 
passed  to  users. 

However,  there  is  a  growing  concern 
drat  acquisition  officials  are  not  aware  of 
this  responsibility  and  are  not  prepared  to 


exercise  SwA  due  diligence  in  the  buying 
process.  To  assist  acquisition  officials  in 
understanding  and  exercising  SwA  due 
diligence,  a  guide  [4]  was  developed  by  a 
working  group  (as  part  of  a  larger  SwA4 
initiative)  on  how  to  incorporate  SwA 
considerations  in  key  decisions  through- 
out  the  acquisition  process. 

This  article  provides  a  summary  of 
five  essential  SwA  considerations  that 
acquisition  officials  should  include  in  their 
decision-making.  These  considerations  are 
extracted  or  synthesized  from  the  acquisi¬ 
tion  guide  developed  by  the  working 
group.  The  acquisition  guide  provides 
more  detailed  discussion  and  explanation 
along  with  additional  considerations. 

Five  Essential  SwA 
Considerations  in  Acquisition 
Decision-Making 

SwA  considerations  should  be  included  in 
each  phase  of  the  acquisition  process 
from  the  initial  acquisition  strategy  and 
plan,  requirements  development,  contract 
or  purchase,  and  contract  administration 
through  follow-on  software  support 
efforts.  The  objectives  of  these  SwA  con¬ 
siderations  are  to  ensure  the  delivery  of 
reliable  software  that  functions  as  promised  and 
software  free  from  security  vulnerabilities  and 
malicious  code. 

Essential  Consideration  #1  -  Build 
Security  In:  Create  Acquisition 
Strategies  and  Plans  That  Include 
Essential  SwA  Considerations 

To  build  security  in,  SwA  considerations 
should  be  planned  from  the  inception  of  a 
software  or  software-intensive  system 
acquisition  through  delivery  and  post¬ 
release  support.  The  Federal  Acquisition 
Regulation  (FAR)  requires  that  an  acquisi¬ 
tion  plan  be  developed  for  all  acquisitions 
and  that  all  plans  discuss  how  agency 


information  security  requirements  are 
being  met  [5].  The  Defense  Acquisition 
Guidebook  requires  program  managers  to 
develop  an  Acquisition  Information 
Assurance  (IA)  Strategy  as  part  of  their 
Acquisition  Strategy  [6],  Whether  devel¬ 
oping  a  strategy  or  plan  in  accordance 
with  the  FAR,  Defense  Acquisition 
Guidebook,  or  another  directive,  SwA 
should  be  part  of  tire  discussion  on  how 
information  security  requirements  are  to 
be  met.  To  that  end,  die  strategies  or  plans 
might  include  a  discussion  on  the  partici¬ 
pation  of  SwA  subject  matter  experts  in 
the  acquisition  process,  initial  SwA  risk 
considerations,  plans  for  including  SwA 
requirements,  SwA  considerations  in  con¬ 
tractor  selection,  and  SwA  considerations 
in  contract  administration  and  project 
management. 

Acquisition  officials  should  require  the 
participation  of  SwA  subject  matter 
experts  in  the  acquisition  process  from 
planning,  requirements  development, 
source  selection,  contract  award  through 
contract  administration,  and  project  man¬ 
agement.  This  is  essential  not  only  for 
establishing  appropriate  SwA  require¬ 
ments,  but  also  in  evaluating  potential 
contractors  and  ensuring  that  secure  soft¬ 
ware  is  delivered.  Acquisition  strategies 
and  plans  should  state  the  level  of  SwA 
expertise  required  as  well  as  specific  state¬ 
ments  of  involvement.  An  example:  This 
acquisition  requires  support  from  an  SwA 
subject  matter  expert.  This  individual  will 
develop  the  SwA  requirements,  evaluate 
the  SwA  aspect  of  proposals,  and  moni¬ 
tor  the  assurance  case  proving  the  deliv¬ 
ery  of  SwA  requirements  during  contract 
performance. 

Strategies  and  plans  should  include  an 
initial  discussion  on  risk  management.  For 
information  assurance/security,  the  secu¬ 
rity  category  (SC)  (based  on  a  range  of 
risk  levels)  should  be  included  in  strategies 
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and  plans.  The  Federal  Informadon 
Processing  Standard  Publication  (FIPS 
Pub)  199  [7]  as  mandated  by  the  Federal 
Information  Security  Management  Act 
(FISMA)  of  2002  requires  that  a  security 
category  be  designated  for  each  software- 
intensive  system.  The  DoD  Instruction 
(DoDI)  8500.2  [8]  provides  security  cate¬ 
gorization5  rules  for  DoD  software -inten¬ 
sive  systems  using  Mission  Assurance 
Categories  (MAC)  and  confidentiality  lev¬ 
els.  The  FIPS  Pub  1 99  states  that  security 
categories  should  be  based  on  the  mission 
that  the  software  is  to  support,  the  envi¬ 
ronment  in  which  the  mission  is  per¬ 
formed,  and,  generally,  the  kind  of  infor¬ 
mation  that  is  generated  and  maintained 
to  support  the  mission  (e.g.,  medical,  pri¬ 
vacy,  classified,  time  sensitive,  warfighter 
combat  information,  financial,  security 
management,  etc.).  Security  categorization 
includes  an  assessment  of  three  security 
objectives  defined  in  FISMA:  confidential¬ 
ity6,  integrity7,  and  availability8  [9],  Two 
examples  follow: 

•  EXAMPLE  1  -  From  FIPS  Pub  199: 

A  law  enforcement  organization  man¬ 
aging  extremely  sensitive  investigative 
information  determines  that  the  poten¬ 
tial  impact  from  a  loss  of  confidential¬ 
ity  is  high,  the  potential  impact  from  a 
loss  of  integrity  is  moderate,  and  the 
potential  impact  from  a  loss  of  avail¬ 
ability  is  moderate.  The  resulting  SC  of 
this  information  type  is  expressed  as: 
SC  investigative  information  =  {confi¬ 
dentiality,  HIGH),  ( integrity ,  MODER¬ 
ATE),  (i availability ,  MODERATE). 

•  EXAMPLE  2  -  [NOTIONAL], 
MAC,  and  Confidentiality  Level:  A 
system  must  provide  access  to  sensi¬ 
tive  and  classified  combat  support 
data.  There  must  be  uninterrupted  ser¬ 
vice  and  data  availability.  The  loss  of 
confidentiality  and  integrity  are  unac¬ 
ceptable  and  could  include  the  imme¬ 
diate  and  sustained  loss  of  mission 
effectiveness.  The  resulting  MAC  and 
confidentiality  level  is  expressed  as: 
Confidentiality-.  TOP  SECRET;  MAC  I: 
Requires  the  most  stringent  of  protec¬ 
tion  measures. 

Acquisition  strategies  and  plans  should 
include  statements  of  critical,  high-level 
SwA  considerations.  These  high-level 
statements  guide  the  ultimate  detailed 
statement  of  requirements.  Acquisition 
officials  developing  acquisition  strategies 
and  plans  should  rely  heavily  on  the  SwA 
personnel  assigned  to  the  acquisition. 
Three  examples  follow: 

•  EXAMPLE  1  -  COTS  Software:  In 
order  to  ensure  that  COTS  is  consis¬ 
tent  with  the  overall  security  require¬ 


ments  of  the  software-intensive  sys¬ 
tem,  SwA  personnel  assigned  to  this 
acquisition  will  provide  requirements 
to  ensure  delivery  of  COTS  that  has 
specified  pre-set  security  settings.  In 
addition,  requirements  will  mandate 
that  testing  of  the  specified  pre-set 
software  be  accomplished  on  the  oper¬ 
ating  system  and  platform  proposed 
for  production. 

•  EXAMPLE  2  -  Software  Develop¬ 
ment  or  Systems  Integration:  To 

manage  the  development  and  delivery 
of  SwA  requirements,  an  SwA  case 
shall  be  developed  that  presents  a  con¬ 
vincing  argument  the  software  will 
operate  in  an  acceptably  secure  manner. 
To  support  the  SwA  case,  definitive  evi¬ 
dence  (e.g.,  processes,  procedures,  test 
results,  etc.)  shall  be  produced  to  pre¬ 
sent  a  convincing  argument  that  die 
software  will  be  acceptably  secure 
throughout  its  life  cycle,  including  ter¬ 
mination.  The  security  stakeholders 
(e.g.,  accreditors)  will  evaluate  the  SwA 
case  in  determining  that  the  software 
will  function  as  expected  and  be  as  free 
of  vulnerabilities  as  possible. 

•  EXAMPLE  3  -  Generally:  The  soft¬ 
ware  shall  address  the  required  securi¬ 
ty  properties  and  functionality,  rele¬ 
vant  laws,  regulations,  standards,  and 
other  legal  and  societal  requirements. 
In  addition,  independent  verification 
and  validation  (IV&V)  shall  be  per¬ 
formed  on  the  code  to  determine  the 
software’s  security  posture.  This  IV&V 
shall  be  performed  by  a  qualified  SwA 
IV&V  entity. 

High-level  statements  on  how  SwA  is 
to  be  considered  in  the  selection  of  con¬ 
tracts  should  also  be  included  in  acquisi¬ 
tion  strategies  and  plans.  As  an  example: 
Due  diligence  questionnaires  will  be  used 
to  solicit  answers  from  offerors  on  their 


SwA  practices.  The  answers  will  be  part  of 
the  evaluation  plan. 

Lastly,  high-level  statements  should  be 
included  in  acquisition  strategies  and  plans 
on  how  SwA  requirements  are  to  be  mon¬ 
itored  during  contract  performance,  for 
example:  SwA  personnel  will  monitor  the 
delivery  of  SwA  requirements. 

Essential  Consideration  #2  -  Require 
Secure  Software:  Include  SwA 
Requirements  in  Software 
Requirements  Document 

The  security  category  is  the  basis  for  SwA 
requirements.  The  FAR  requires  that  fed¬ 
eral  agencies  use  FIPS  pubs  for  IT  stan¬ 
dards  and  guidance  [10].  The  FIPS  Pub 
200  includes  guidance  on  minimum  secu¬ 
rity  requirements  for  federal  information 
and  information  systems  [11].  The 
National  Institute  for  Standards  and 
Technology  Special  Publication  (NIST  SP 
800-53)  provides  specific  security  control 
requirements  based  on  security  category 
[12],  and  the  DoDI  8500.2  contains  secu¬ 
rity  control  requirements  based  on  mis¬ 
sion  assurance  category  for  the  DoD.  The 
guide  for  acquisition  officials  includes 
additional  sources  for  SwA  requirements, 
as  well  as  some  examples.  Table  1  shows 
examples  of  general  requirements  of  SwA 
that  acquisition  officials  should  consider, 
including  statements  of  work  or  terms 
and  conditions.  Table  2  shows  specific 
requirements  of  SwA. 

Essential  Consideration  #3  -  Be  an 
Educated  Consumer:  Ask  the  Right 
Questions  During  the  Contracting 
Process 

Knowing  what  to  ask  and  asking  the  right 
questions  regarding  offerors’  SwA  envi¬ 
ronments  is  essential  in  determining  how 
well  offerors’  meet  business  and  technical 
goals  for  SwA.  The  guide  for  acquisition 


Table  1:  Examples  of  General  SwA  Requirements 


General  Requirements 

•  Definitions  relative  to  SwA  for  a  common  understanding. 

•  A  full  explanation  of  the  SC. 

•  Assurance  case  that  addresses  the  SwA  requirements  (see  more  in  Essential 
Consideration  #4). 

•  SwA  acceptance  criteria  (associated  with  the  SwA  case). 

•  SwA  risk  management  that  includes  a  formal  program  for  risk  management. 

•  Consideration  for  auditing  code  for  security  by  an  independent  body. 

•  Software  Architecture  that  includes  SwA  components. 

•  A  security  test  plan  that  defines  the  approach  for  testing  SwA  requirements. 

•  Configuration  guidelines  for  all  security  configuration  options. 

•  Legal  responsibilities  relative  to  SwA. 

•  Qualifications  and  required  SwA  training  of  software  personnel. 

•  Identification  of  key  security  personnel. 

•  Required  information  relative  to  foreign  ownership,  control,  or  influence. 
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officials  includes  sample  software  due-dili¬ 
gence  questionnaires  for  various  types 
(e.g.,  COTS  only,  software  integration  ser¬ 
vices,  software  development,  etc.)  of  soft¬ 
ware  acquisitions.  These  questionnaires 
provide  the  acquisition  official  a  means  to 
gather,  in  advance,  some  of  the  informa¬ 
tion  needed  to  make  a  decision  about 
whether  it  offers  the  process  capabilities 
to  deliver  reliable  software  that  functions  as 
promised  and  software  free  from  security  vulnera¬ 
bilities  and  malicious  code. 

Questionnaires  may  be  used  informal¬ 
ly  or  incorporated  into  a  formal  process. 
For  example:  Informally,  the  buyer  of 
COTS  software  may  apply  the  questions 
to  conduct  market  research  into  COTS 
products  available  to  satisfy  an  organiza¬ 
tion’s  software  requirements.  Formally,  the 
acquisition  official  may  incorporate  ques¬ 
tions  into  a  Request  for  Information  or 
Request  for  Proposal  (RFP)  as  part  of  a 
major  software-intensive  system  acquisi¬ 
tion.  Answers  to  the  questions  form  a 
basis  for  evaluating  offers. 

Questions  in  a  software  due  diligence 
questionnaire  may  be  organized  into  cate¬ 
gories  that  represent  a  logical  grouping  of 
SwA  concerns  such  as  organization  back¬ 


ground,  software  production  policies, 
software  pedigree,  assurance,  preventive 
measures,  quality  control,  operations  and 
support,  and  service  governance.  Table  3 
lists  a  partial  set  of  example  questions  that 
may  be  used  in  the  acquisition  of  custom 
software  development  services  (the  guide 
includes  the  comprehensive  set  of  ques¬ 
tions). 

Essential  Consideration  #4  -  Demand 
Delivery  of  Secure  Software:  Ensure 
SwA  Requirements  Are  Met  During 
Contract  Administration  and  Project 
Management 

Acquisition  officials  should  ensure  that  all 
the  SwA  requirements  are  adequately 
monitored  and  implemented.  This 
includes  work  plan  management,  assur¬ 
ance  case  management,  software  risk  man¬ 
agement,  and  final  acceptance  of  the  soft¬ 
ware  product  or  service. 

Acquisition  officials  must  ensure  that 
SwA  requirements  are  specifically  includ¬ 
ed  in  a  contract  work  plan  and/or  work 
breakdown  structure,  if  required.  SwA 
subject  matter  experts  should  be  used  to 
ensure  that  SwA  requirements  are  includ¬ 
ed  in  the  work  plan. 


Acquisition  officials  must  ensure  that 
the  SwA  case  is  managed  in  accordance 
with  the  contract  and  should  be  managed 
as  part  of  the  acquisition  risk  manage¬ 
ment  strategy.  The  development  of  an 
SwA  case  is  an  iterative  process  through¬ 
out  a  system’s  life  cycle  and  contains  a 
plethora  of  claims  and  evidence  types  not 
collated  or  contained  together. 
Therefore,  the  SwA  case  must  be  devel¬ 
oped  and  managed  in  such  a  fashion  that 
all  evidence  is  able  to  be  preserved, 
traced,  and  accessed.  Throughout  the 
acquisition  life  cycle,  SwA  case  reports  — 
as  stipulated  in  the  contract  —  should  be 
delivered  at  key  project  milestones.  These 
reports  should  be  reviewed  by  appropri¬ 
ate  SwA  subject  matter  experts  for  issues 
and  recommendations.  Acquisition  offi¬ 
cials  must  ensure  that  periodic  reviews  of 
the  SwA  case  are  transparent  and  any 
corrective  actions  are  followed  to  a  con¬ 
clusion  prior  to  acceptance  of  the  case 
argument.  Example  issues  related  to  SwA 
case  management  during  contract  perfor¬ 
mance  include  the  following: 

•  Performance.  Is  the  SwA  case  devel¬ 
opment  progressing  in  accordance 
with  contract  requirements?  Are  pro¬ 
ject  technical  milestones  incorporating 
SwA  case  review?  Does  the  SwA  case 
comply  with  contract  requirements, 
including  regulations  and  certification 
requirements? 

•  Resources.  Has  the  contractor  allo¬ 
cated  appropriate,  qualified  personnel 
to  the  task?  Is  the  SwA  case  being 
developed  with  appropriate  tools?  Is 
the  SwA  case  budget  realistic? 

•  Quality.  Is  the  supplier  engaging  the 
right  acquisition  officials  to  review  the 
acceptability  of  the  SwA  case?  Are 
corrective  actions  being  followed  up 
adequately?  Are  the  contractor’s 
claims,  arguments,  and  evidence  suffi¬ 
ciently  robust  and  commensurate  with 
risk? 

•  Time.  Is  the  SwA  case  development 
on  schedule  and  fully  integrated  with 
software  system  development? 

Final  acceptance  should  be  based  on  the 
acceptance  of  the  final  SwA  case.  Criteria 
for  acceptance  should  be  explicit  and 
included  in  the  SwA  case. 

Essential  Consideration  #5  -  Continue 
SwA  for  the  Life  of  the  Software: 
Maintain  SwA  in  Follow-On  Support 

Follow-on  support  is  the  logistics  tail  in 
the  acquisition  of  software.  Additional 
contracts  are  often  awarded  to  provide 
support  during  this  phase.  There  should 
be  ongoing  analyses  to  ensure  that  securi¬ 
ty  requirements  remain  adequate.  To  that 


Table  2:  Exatnples  of  Specific  SwA  Requirements 


Specific  Requirements 

•  A  server-side  software  application  shall  never  rely  on  the  client  to  perform  input 
validation.  The  server  application  should  always  validate  any  input  it  receives, 
regardless  of  whether  that  input  was  previously  validated  by  the  client. 

•  The  software  application  shall  verify  that  the  actual  results  match  the  expected 
results  criteria. 

•  The  software  application  shall  prevent  any  entity  from  performing  application 
functions  that  entity’s  authorizations  do  not  explicitly  permit  it  to  perform. 

•  Server/Web  service  that  authenticates  based  on  role  or  group  authentication  shall 
perform  individual  authentication  first. 

•  Authentication  technology  shall  be  implemented  based  on  published  open 
standards. 

•  Code  shall  meet  organizational  and  industry  standards,  conform  to  a  consistent 
style  guideline  (code  format),  and  shall  be  well  documented. 

•  Appropriate  security  metrics  shall  be  used  during  security  review/audit  in  the 
software  life  cycle  to  measure  the  degree  to  which  security  criteria/requirements 
have  or  have  not  been  satisfied. 

•  Security  testing  shall  be  performed  both  on  individual  units/components  and  on  the 
whole  integrated  software  application. 

•  Error  messages  shall  not  reveal  more  details  than  necessary  about  the  software 
application. 

•  No  software  developer  backdoors,  debug  interfaces,  or  unauthorized  access  paths 
shall  be  present  in  the  production  version  of  the  software. 

•  After  it  goes  into  production,  the  software  application’s  security  posture  shall  be 
periodically  reviewed  to  ensure  that  new  vulnerabilities  have  not  emerged. 

•  The  software  application  shall  continue  functioning,  possibly  in  a  degraded  mode, 
when  subjected  to  input  patterns  that  indicate  a  denial  of  service  attack. 

•  Any  COTS  software  shall  be  configured  in  accordance  with  security  configurations 
specified  in  the  statement  of  work.  The  contractor  shall  provide  written  assurance 
that  the  software  operates  as  intended  and  as  initially  configured  with  each 
subsequent  software  release. 
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Partial  Set  of  Example  Questions 

.  How  does  your  company  use  security  best  practices  that  are  designed  to 
address  security  concerns  in  the  software  development  life  cycle  (SDLC)? 

•  Are  there  formal  software  quality  policies  in  place?  How  are  they  enforced? 

•  What  measurement  practices  and  data  does  your  company  use  to  enable  realistic 
project  planning,  timely  monitoring  of  project  progress  and  status,  identification  of 
project  risks,  and  effective  process  improvement? 

•  What  training  does  your  company  offer  related  to  defining  security  requirements, 
secure  architecture  and  design,  secure  coding  practices,  and  security  testing? 

•  Describe  the  company’s  policy  and  process  for  professional  certification  of 
developers  and  ensuring  certifications  are  valid  and  up-to-date. 

•  Are  security  requirements  developed  independently  of  the  rest  of  the  requirements 
engineering  activities,  or  are  they  integrated  into  the  mainstream  requirements 
activities?  Explain. 

•  What  threat  modeling  process,  if  any,  is  used  when  designing  the  software?  What 
analysis,  design,  and  construction  tools  are  used  by  your  software  design  teams? 
What  security  design  and  security  architecture  artifacts  are  produced?  How  are 
they  maintained? 

•  Does  the  software  development  plan  include  peer  reviews  for  quality  and  security? 

•  Are  tools  provided  to  help  developers  verify  that  the  software  they  have  produced 
is  free  of  defects  that  could  lead  to  vulnerabilities?  What  are  they? 

•  Explain  how  your  company  ensures  that  software  is  able  to  detect,  recognize,  and 
respond  to  attack  patterns  in  input  it  receives  from  human  users  and  external 
processes? 

•  Are  static  or  dynamic  software  security  analysis  tools  used  to  identify  vulnerabilities 
in  the  software?  If  yes,  what  tools  are  used?  What  classes  of  vulnerabilities  are 
covered? 

•  Are  security-specific  regression  tests  performed  during  the  development  process? 
How  broad  is  the  test  coverage?  How  frequently  are  security-specific  regression 
tests  performed? 

•  What  policies  and  processes  does  your  organization  use  to  verify  that  software 
components  do  not  contain  unintended,  dead,  or  malicious  code?  What  tools  are 
used? 

•  Does  your  company  perform  background  checks  on  members  of  the  software 
development  team?  If  so,  are  there  any  additional  vetting  checks  done  on  people 
who  work  on  critical  application  components,  such  as  security?  Explain. 

•  Does  your  company  have  formally  defined  security  policies  associated  with  clearly 
defined  roles  and  responsibilities  for  personnel  working  within  the  SDLC,  including 
work  that  is  subcontracted  or  outsourced,  along  with  management  oversight  and 
enforcement?  Explain. 


Table  3:  Partial  Set  of  Questions  for  Custom  Software  Development  Services 


end,  acquisition  officials  should  ensure 
that  the  assurance/security  requirements 
implemented  and  accepted  in  previous 
contracts  flow  to  the  follow-on  contract 
efforts.  Additionally,  acquisition  officials 
should  ensure  that  contract  language  is  in 
place  to  guide  the  transition  process  from 
an  incumbent  contractor  to  a  new  con¬ 
tractor  responsible  for  follow-on  support. 

Information  systems  are  typically  in  a 
constant  state  of  migration  with  upgrades 
to  hardware,  software,  or  firmware  and 
possible  modifications  to  the  surrounding 
environment  of  the  system.  Weak 
change/configuration  control  procedures 
can  corrupt  software  and  introduce  new 
security  vulnerabilities.  Therefore,  acquisi¬ 
tion  officials  should  ensure  that  strong 
change /configuration  control  flows  to 
follow-on  contract  efforts. 

Patches  and  upgrades  make  direct 
changes  to  software  and  potentially  the 
configuration  of  the  operating  system  to 
which  they  are  applied.  Changes  may 
degrade  performance,  introduce  new  vul¬ 
nerabilities,  or  reintroduce  old  vulnerabili¬ 
ties.  In  order  to  understand  patch  risks, 
the  patch  process  must  be  examined  in 
some  detail  during  the  initial  acquisition 
and  again  when  follow-on  support  con¬ 
tracts  are  awarded.  One  of  the  most  com¬ 
mon  patch  failures  stems  from  a  lack  of 
encryption  and  authentication  in  the 
implementation  phase.  Suppliers  should 
provide  updates  in  a  secure  fashion.  There 
should  be  no  doubt  that  the  source  is 
legitimate  and  the  update’s  integrity  is 
maintained  in  transit. 

Conclusion 

Large  numbers  of  vulnerable  software- 
based  systems  exist  today,  in  many  cases 
due  to  the  acquisition  of  vulnerable  soft¬ 
ware.  The  rampant,  worldwide  increase  in 
exploitation  of  software  vulnerabilities 
demands  that  acquisition  officials  not  only 
check  for  acceptable  functionality,  but  also 
achieve  acceptable  SwA.  Security  cannot 
be  bolted  on  after  software  services  and 
products  are  delivered.  To  that  end,  acqui¬ 
sition  officials  must  become  educated 
consumers  in  the  purchase  of  secure  soft¬ 
ware,  and  each  phase  of  the  acquisition 
process  must  be  leveraged  to  build  security 
in  to  ensure  the  delivery  of  reliable  software 
that functions  as  promised  and  software  free  from 
security  vulnerabilities  and  malicious  code.+ 
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Notes 

,f.  The  views  expressed  in  this  article  are 
those  of  the  authors  and  do  not 
reflect  the  official  policy  or  position 
of  the  National  Defense  University, 
the  DoD,  or  the  U.S.  government. 

2.  SwA  is  the  level  of  confidence  that 
software  is  free  from  vulnerabilities, 
either  intentionally  designed  into  the 
software  or  accidentally  inserted  at 
anytime  during  its  life  cycle,  and  the 
software  functions  in  the  intended 
manner  (CNSS  Instruction  No.  4009). 

3.  The  generic  term  acquisition  official  is 
used  throughout  this  article  to  mean 
the  contracting  officers  or  purchasing 
officials  and  other  members  of  the 
purchasing  team.  Members  of  the 
purchasing  team  may  include  person¬ 
nel  who  develop  requirements  and 
statements  of  work  for  contracts, 
contracting  officer  representatives  to 
include  contracting  officer  technical 
representatives,  or  program/project 
managers. 

4.  In  2003,  the  DoD  launched  an  SwA 
initiative  led  by  Joe  Jarzombek.  This 
was  joined  in  2004  by  the  DHS  to 
address  concerns  of  poor-quality, 
unreliable,  and  non-secure  software. 
In  March  2005,  Jarzombek  moved  to 
DHS  as  the  Director  for  SwA, 
National  Cyber  Security  Division 
(NCSD).  He  provides  the  leadership 
in  the  collaborative  SwA  efforts. 
Several  working  groups  (with  mem¬ 
bers  across  government  agencies, 
industry,  and  academia)  were  estab¬ 


lished.  The  initial  working  groups  for 
DHS  including  the  following: 

•  Software  technology,  tools,  and 
product  evaluation. 

•  Software  acquisition. 

•  Software  processes  and  practices. 

•  Software  workforce  educational 
and  training. 

The  goal  of  the  SwA  Acquisition 
working  group  is  to  look  at  how  to 
enhance  software  supply  chain  man¬ 
agement  through  improved  risk  miti¬ 
gation  and  contracting  for  secure 
software.  The  overwhelming  recom¬ 
mendation  of  the  group  is  the  devel¬ 
opment  of  a  guide  that  provides  due- 
diligence  questionnaires,  sample  tem¬ 
plates,  and  sample  language  that  could 
be  used  in  statements  of  work,  RFPs, 
and  contracts. 

5.  The  FISMA  of  2002  requires  the 
development  of  security  categoriza¬ 
tion  standards.  The  security  cate¬ 
gories  are  the  basis  for  establishing 
information  security  requirements 
based  on  a  range  of  risk  levels.  See 
FIPS  Pub  199  for  security  categoriza¬ 
tion  of  information  and  information 
systems  that  form  a  basis  for  confi¬ 
dentiality,  availability,  and  integrity 
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requirements.  Also  see  DoD  8500 
policies  regarding  security  categoriza¬ 
tion-mission  assurance  categories. 
The  DoD  has  three  defined  mission 
assurance  categories  that  form  the 
basis  for  availability  and  integrity 
requirements.  Confidentiality  require¬ 
ments  are  based  on  the  security  classi¬ 
fication  of  information. 

6 .  ...  preserving  authorised  restrictions  on  infor¬ 
mation  access  and  disclosure,  including 
means  for  protecting  personal  privacy  and 
proprietary  information  [44  U.S.C.,  Sec. 
3532],  A  loss  of  confidentiality  is  the 
unauthorized  disclosure  of  informa¬ 
tion. 

7.  ...  guarding  against  improper  information 
modification  or  destruction,  and  includes 
ensuring  information  non-repudiation  and 
authenticity  [44  U.S.C.,  Sec.  3532],  A 
loss  of  integrity  is  the  unauthorized 
modification  or  destruction  of  infor¬ 
mation. 

8.  ...  ensuring  timely  and  reliable  access  to  and 
use  of  information  [44  U.S.C.,  Sec.  3532], 
A  loss  of  availability  is  the  disruption 
of  access  to  or  use  of  the  software¬ 
intensive  system. 
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